Архитектура и функциональные возможности

Система Global ST^eP предназначена для финансовых организаций, профессиональных участников рынка ценных бумаг. В первую очередь система адресована крупным организациям, которые сталкиваются с необходимостью обработки большого ежедневного объема транзакций (сделок), и нуждаются в высокой степени автоматизации, в том числе и в такой плохо формализуемой задаче, как обработка корпоративных действий.

В основу архитектуры системы Global ST^eP положен современный принцип STP (straight-through processing), который определяется как непрерывный электронный процесс, обеспечивающий полный цикл исполнения финансовых транзакций и связанных с ними бизнес-процессов от выполнения на бирже до утверждения (перерегистрации) и последующих сверок.

Кроме автоматизации выполнения сделок здесь делается акцент на связанные бизнес-процессы, такие как корпоративные действия, залоги ценных бумаг, выплаты дивидендов и доходов.  Такое понимание STP характерно для SIA (Securities Industry Association – международная ассоциация индустрии ценных бумаг).

Архитектура системы разработана как с учетом потребностей российских финансовых организаций, так и в соответствии с зарубежными стандартами. Эффективность технологии подтверждена длительной эксплуатацией в организациях Москвы и Нью-Йорка.

1         Принципы архитектуры

1.1      Структура проекта

Система Global ST^eP предназначена для финансовых организаций, профессиональных участников рынка ценных бумаг. В первую очередь система интересна крупным организациям, которые сталкиваются с обработкой больших ежедневных объемов транзакций (сделок), и нуждаются в высокой степени автоматизации, в том числе и в такой плохо формализуемой задаче, как обработка корпоративных действий.

Global ST^eP  не является «коробочным» программным продуктом. Отличия стандартов бизнеса профессионального рынка ценных бумаг в разных организациях и странах не позволяет разработать единую систему, удовлетворяющую большинству участников рынка.

Поэтому, каждая конкретная реализация архитектуры Global ST^eP   имеет следующую структуру программного обеспечения

1.      Ядро системы, реализующее все основные бизнес-процессы «в общем виде»

2.      Настройка системы в соответствии с бизнес-требованиями Заказчика. 

3.      Реализация функций, специфичных для данного Заказчика. 

Установка ядра системы является стандартной операцией и выполняется за несколько дней, включая задачу конфигурирования серверов и систем управления базами данных.

Настройка ядра по требованиям Заказчика требует участия последнего в части формулировки требований к системе. Бизнес-требования всегда включают большое количество важных деталей. Чтобы зафиксировать все детали и перенести их в систему используется специальная технология. На основе требований Заказчика строятся «частично формализованные» схемы бизнес-процессов с использованием объектно-ориентированных моделей (OMT/UML). Затем эти требования строго формализуются в виде XLS таблиц. Данные таблицы снабжены макросами, которые позволяют сгенерировать необходимый код, что автоматизирует процесс настройки системы. Настройка системы занимает 1-2 недели, при условии что требования к системе сформулированы Заказчиком (в любом виде, но с достаточной детализацией).

Реализация специфичных функций, это единственный этап, требующий кодирования. На практике эта часть не превышает 5% общего объема программного кода системы.

1.2      Ручная и автоматическая обработка

Архитектура Global ST^eP предполагает, что практически все операции могут выполнятся как автоматически так и вручную. Соответствующие настройки определяются предпочтениями Заказчика, зависят от возможностей внешних систем, с которыми Global ST^eP должна взаимодействовать и от доступности внешних источников финансовой информации.

Примеры действий, которые могут выполняться автоматически

• Прием и обработка финансовых сообщений.
  Пример. Сообщение, полученное модулем SWIFT (MT541) автоматически создает сделку в системе. Подтверждение, полученное от кастодиана (MT545), приводит к автоматическому утверждения сделки в системе. Сообщение о перечислении дивидендов (MT566) создает бухгалтерскую проводку, которую бухгалтеру достаточно авторизовать.
• Отправка финансовых сообщений.
  При продвижении сделки с одного шага обработки на другой отправляются соответствующие сообщения участникам сделки (клиенту, кастодиану и т.п.). Global ST^eP имеет интегрированные механизмы отправки SWIFT-сообщений, а также сообщений по e-mail и по факсу.
• Выписки со счета
  система формирует и отправляет автоматически. Для каждого счета можно задать график отправки – ежедневно, еженедельно, ежемесячно и т.п.
• Продвижение сделки.
  Переход сделки с шага на шаг может инициироваться получением финансового сообщения (SWIFT) или наступлением определенной даты (в определенных бизнес-сценариях сделки гарантированно выполняются в заданные сроки).
• Бухгалтерский и депозитарный учет.
  При переходе сделки с шага на шаг автоматически выполняются  соответствующие бухгалтерские проводки. В случае отмены сделки или возврате на предыдущий шаг проводки реверсируются.
• Загрузка котировок и курсов валют.
  Получение цен финансовых инструментов и курсов валют из внешних источников обычно происходит раз в день. Котировки и курсы используются при различных расчетах, при формировании отчетов и финансовых сообщений.
• Загрузка и обработка корпоративных действий.
  Получение информации о корпоративных действиях (КД) тоже происходит ежедневно. Система имеет интерфейсы к ряду агентств, поставляющих данную информацию в формализованном виде (Telekurs[1], Швейцария; Xcitek[2], Северная Америка). Кроме того, автоматически обрабатываются SWIFT-оповещения о КД (MT564, MT568). Global ST^eP автоматически создает записи о корпоративных действиях. Для распознавания оповещений, относящиеся к одному и тому же КД используются эвристические процедуры.
• Оповещение клиентов о корпоративных действиях.
  Все держатели ценных бумаг, по которым производятся корпоративные действия, автоматически оповещаются - по SWIFT, e-mail или по факсу.

 

2         Основные модули системы

Рис. 1. Общая схема модулей системы и потоков данных.

2.1      Модуль статических данных (Static Data)

Модуль предназначен для хранения, импорта, ввода и редактирования данных об основных бизнес-сущностях системы.

• Финансовые инструменты. Система хранит около 1 млн. различных ценных бумаг. Для классификатор применяется CFI (ISO 10962) . Для идентификации может  применяться одновременно несколько систем, например, ISIN, CUSIP, российский номер гос. регистрации.
• Котировки инструментов импортируются из внешних источников. В Российских версиях используются данные AK&M и РТС. В глобальной версии для западного рынка – Telekurs. «Глубина» истории цен ограничена только объемом баз данных. Например, в западной реализации при среднем количестве котировок около 500,000 в день цены хранятся до 50 дней. Если база данных содержит только российские бумаги, то историю цен можно считать практически неограниченной.
• Курсы валют. Система автоматически загружает и хранит кросс-курсы практически всех известных валют. Курсы используются для разнообразных расчетах при проведении сделок,  для формирования отчетов и финансовых сообщений.
• Клиенты, счета. Данные о клиентах финансовой организации и об открытых для них счетах. 
• Внутренний учет. Данные о счетах внутреннего бухгалтерского и депозитарного учета кредитной организации. 
• Участники сделок. Данные о прочих участниках бизнес-процессов – биржах, депозитариях, регистраторах, кастодианах, брокерах, контрагентах. Для каждого участника определяется, в каких ролях он может выступать в транзакциях. Совокупность ролей определяет «бизнес-профиль» физического или юридического лица.
• Прейскурант комиссионных сборов. Разнообразные виды комиссионных за услуги финансовых организаций – за проведение сделок, за хранение ценных бумаг, за открытие и за обслуживание счетов клиентов и т.п. Система позволяет использовать гибкие прейскуранты: тариф может зависеть от типа сделки, от территориальной зоны расположения реестра, от биржи, от конкретного счета клиента и т.п. Комиссии может задаваться фиксированным значением или в базисных единицах (basis points). Можно использовать ступенчатую шкалу с минимальным и максимальными значениями.
  Система автоматически использует прейскуранты для расчетов финансовых параметров сделки, как при ее автоматическом создании, так и при вводе . редактировании сделки вручную.
• Налоговые ставки по видам налогов. Налоги используется при расчете раздичных сумм, фигурирующих в сделке, при формировании финансовых сообщений (SWIFT) и отчетов.
• Адресная книга. Данные об адресах, по которым отправляются финансовые сообщения клиентам  и другим участникам транзакций (кастодианам, брокерам и т.п.) Для каждого адресата можно задать несколько SWIFT, e-mail и факс-адресов. Правила выбора конкретного адреса для каждого случая задаются дополнительными настройками. Например, уведомление о начале сделки можно направлять на SWIFT(1), о ее завершении на SWIFT(2), а ежедневные выписки со счета -  по e-mail.
• Календарь выходных дней. Используется для вычисления интервалов дат, заданных в рабочих днях (например, «утверждение сделки по схеме T+3»). Также используется планировщиком автоматических процессов. Например, «загружать котировки только по рабочим дням», «посылать выписку по счету ежедневно от вторника до субботы».
• Отчеты. В модуль Статических Данных включены отчеты имеющие вид Списков:  инструменты, счета, клиенты, биржи, брокеры  и т.п. Обычно полные списки имеют слишком большие объемы, поэтому система предоставляет гибкие механизмы поиска и фильтрации, чтобы ограничить объем интересующей информации до разумного для вывода на экран и печать.
• Дополнительные сервисы
  • Блокировка, разблокировка счетов клиентов.
  • Блокировка, разблокировка инструмента, то есть приостановка выполнения транзакций с участием данной ценной бумаги.
  • Настройка адресов отправления финансовых сообщений в зависимости от конкретных бизнес-ситуаций. Отдельно настраиваются сообщения, связанные с продвижением сделок, выписки со счетов. оповещения о корпоративных действиях.
  • Разнообразные настройки, необходимые в системе для автоматической обработки финансовых сообщений

2.2      Модуль сделок (Settlement)

Модуль предназначен для ручного выполнения шагов транзакций и для контроля за их автоматическим выполнением.

Каждая сделки в системе имеет рядом характеристик –

·        Тип транзакции. Основные типы - покупка, продажа, свободное получение, свободная поставка, получение против платежа, поставка против платежа, внутренняя проводка.

·        Сценарий. Сделки одного и тот же типа могут иметь различные сценарии. Обычно в каждой организации для каждого типа сделки существует лишь несколько сценариев. Примеры сценариев: Утверждение по Контракту, Утверждение по Факту, Кастодиальная Услуга.  Сценарий определяет:

o       совокупность состояний, которые сделка может проходить при ее выполнении

o       стимулы, приводящие к смене состояния (вручную, по приходу определенного финансового сообщения, по наступлению определенной даты)

o       типовые бухгалтерские проводки, автоматические записываемые в бухгалтерские книги при каждой операции со сделкой

o       типы финансовых сообщений, отправляемые на каждом переходе

o       уведомления, автоматические распечатываемы при прохождение шагов сделки

o       проверки, которые система должна выполнить, прежде чем выполнить смену состояния

o       дополнительные действия, которые выполняются при прохождении шагов сделки (вычисления, конвертация валют и т.п.)

·        Путь сделки.  Путь - это внутреннее понятие системы, фактически представляющее совокупность типа сделки и ее сценария. Система определяет путь в момент инициации сделки (ручного или автоматического) на основе ее характеристик. Путь определяет весь закон дальнейшего поведения сделки. Путь нельзя изменить, если сделка уже ушла из начального состояния.  Для смены пути сделки или числовых данных (счета, количество бумаг, денежные суммы) необходимо вернуть сделку в начальное состояние, что приводит к автоматическому «реверсированию» всех бухгалтерских проводок, порожденных данной сделкой. Кроме того, автоматически будут разосланы сообщения о «перезаведении» сделки.

Типы / сценарии / пути сделок тщательно оговариваются с Заказчиком перед настройкой системы. При достаточной квалификации и подготовке IT-штата Заказчика, он может самостоятельно справится с этой задачей.

Для общего описания пути используется объектно-ориентированная диаграмма, на основе которой  готовятся настроечные данные (в виде XLS-таблиц). Эти таблицы снабжены макросами, которые на основе настроечных данных генерируют программный код. Таким образом, процесс настройки системы

На рисунке приведен фрагмент схемы, представляющий в объектно?ориентрированном виде путь сделки. Схема подготовлена с помощью Rational Rose 2000[3].

Рис. 2 Схема пути сделки - объектно-ориентированное представление.

Основными атрибутами сделки являются: 

• Количество ценных бумаг. Допускается «partial fill», т.е. объединение в одну сделку нескольких порций, приобретенных / проданных по различным ценам.
• Счет клиента и все счета внутреннего учета, используемые в сделке.
• Различные денежные суммы. Сценарий сделки определяет, каким образом денежные суммы используются в типовых проводках бухгалтерского учета.
• Все даты связанные со сделкой.
• Документы, являющиеся основанием для проведения сделки.
• Комментарии, внесенные пользователями, выполнявшими шаги транзакции.
• Финансовые сообщения, связанные с данной сделкой, как входящие, так и исходящие.
• Бухгалтерские проводки, денежные и по бумагам, порожденные данной сделкой.
• Кроме того, создание и все операции со сделкой порождают записи в системном журнале событий, по которым можно проверить кто, когда и что делал с данной транзакцией.

Перечисленная информация доступна для просмотра и редактирования в Окне Сделки.

В системах основанных на STP, как правило, используются относительно простые пути сделок, что обеспечивает высокую скорость и объем финансовых транзакций.

При «прямом» движении сделки она проходит состояния День Сделки -> День Утверждения -> Расчеты -> Финал.
Кроме того, есть состояние Удалено (для отмененных сделок).

В российской практике, при преимущественно ручном проведении транзакций, часто добавляют промежуточные состояния, в которых прохождение сделки контролирует руководитель, а также специальные состояния, в которых подготавливается и проверяется пакет документов, необходимых для перерегистрации ценной бумаги.

Все эти различия определяются при настройке.

В принципе, настройку может выполнять ИТ-отдел Заказчика после прохождения соответствующего обучения.

Рис.3. Список сделок, детали сделки, SWIFT-сообщение, породившее сделку.

 

 

 

Модуль проведения сделок включает следующие функции .

• Списки сделок. В одном окне отображаются все сделки, имеющие определенное состояние. Иногда целесообразно объединить в одном окне несколько состояний, имеющих родственный характер. Например, удобно различать только что созданные сделки (состояние: День Сделки) от сделок, возвращенных на начальное состояние по какой-либо причине. Для этого возвращенным сделкам присваивают другое состояние (Исправление). Однако сделки в состояниях День Сделки и Исправление  группируются в одном окне.
• Список удаляемые сделок. Это окно полностью аналогично окну Список сделок. В системе удаление сделки происходит обычно в 2 шага – «пред?удаление» и окончательное удаление. Из каких состояний разрешено удаление сделки полностью зависит от бизнес?правил Заказчика и решается на этапе настройки системы. В принципе, возможно даже удаление уже завершенной сделки (post-settlement cancellation). Пред-удаление может осуществляться вручную или автоматически по получению определенных финансовых сообщений (от клиента, от брокера, из клиринговой компании). Авторизованное лицо, имеющее доступ к пред-удаленным сделкам решает удалить ли ее окончательно или вернуть в обработку.
• Окно сделки показывает все атрибуты одной сделки (см. выше). В зависимости от состояния, на котором находится транзакция, окно сделки открывается для редактирования или только для просмотра.
• Сверка является механизмом сравнения данных модуля депозитарного и финансового учета с аналогичными данными других организаций (депозитариев, регистраторов, брокеров). Данные для сверки могут вводиться вручную (например, на основе выписок регистраторов) или получаться в виде входящих финансовых сообщений. Система обрабатывает данные для сверки полученные в виде MT535 (выписка позиций), MT536 (выписка транзакций), MT950 (выписка с валютного счета). Также поддерживаются устаревшие форматы выписок  MT571 и MT572. 
• Рассылка выписок по счету. Обычно этот процесс выполняется автоматически. В модуле проведения сделок имеется возможность отправить эту информацию вручную. Поддерживаются те же типы SWIFT сообщений, перечисленные  предыдущем пункте. Для клиентов, не использующих SWIFT сообщения преобразовываются в форму e-mail или факсимильного сообщения.
• Расчет кастодиальной комиссии. Эта функция также может выполняться автоматически или вручную. Для каждого счета хранения системы вычисляет комиссию с заданной частотой (еженедельно, или 1, 2, 4, 12 раз в год) и в соответствии с прейскурантом (см. Модуль Статических Данных) и создает необходимые проводки в Модуле Бухгалтерского Учета. Как правило, проводки авторизуются («букируются») вручную.
• Отчеты и Запросы. Система обладает широким набором отчетов и запросов. Отчеты отформатированы для печати.   Запросы - это специальные выборки из базы данных, необходимые в повседневной работе. Примеры запросов –
  • Транзакция по ее номеру
  • Активные транзакции – по инструменту, по счету, в диапазоне дат
  • Завершенные транзакции – по инструменту, по счету, в диапазоне дат
  • Отмененные транзакции – по инструменту, по счету, в диапазоне дат
  • Бухгалтерские проводки – по счету, по инструменту, по транзакции
• Примеры отчетов (по бумагам)
  • Позиции по  инструменту/эмитенту/клиенту на определенную дату с разбивкой по местам хранения
  • Полученные выписки  и их согласование с данными системы
  • Выписки со счетов ДЕПО клиентов
  • Раскрытие  реальных собственников акций
  • Отчет о депозитарных операциях
  • Ведомость остатков на корреспондентских счетах
  • Суммарная оборотная ведомость по депозитарным операциям
• Примеры отчетов (по сделкам)
  • Передаточные распоряжения
  • Уведомления о сделках
  • Списки и параметры сделок по разным критериям (открытые,  удаленные, отмененные, зарегистрированные в реестре, с задержкой регистрации, по регионам и т.д.)
  • Завершенные сделки по регистраторам/Депозитариям/ТрансферАгентам
• Примеры отчетов (по бухгалтерии)
  • Оборотно-сальдовая ведомость
  • Журнал бухгалтерских операций
  • Отчет  о прибылях и убытках
  • Балансовая ведомость
• Бухгалтерские сервисы. Основные бухгалтерские проводки система выполняет автоматически при продвижении транзакций с одного статуса на другой. Кроме того, в системе предусмотрен интерфейс к модулю бухгалтерского и депозитарного учета, который позволяет выполнить многие проводки вручную. Набор бухгалтерских сервисов (типовых проводок) определяется на этапе настройки системы. Кроме того, есть универсальный сервис, позволяющий сконструировать любую исправительную проводку. При «букировании» проводки система следит за соблюдением  бухгалтерского баланса. 
• Дивиденды и доходы по облигациям. Дивиденды по акциям и доходы по долговым бумагам первоначально  обрабатываются модулем Корпоративных действий. Информация о них заносится или вручную, или автоматически из внешних источников. При получении финансового сообщения (SWIFT MT566) о платеже от эмитента (или платежного агента) модуль корпоративных действий  соответствующие проводки в модуле бухгалтерского учета. Аналогично создаются проводки при наступлении даты выплат клиентам, а также генерируются исходящие MT566.
• Пользовательский интерфейс к подсистеме платежей по дивидендам и доходам находится в приложении Сделки. Пользователь имеет возможность проверить подготовленные платежи, сопоставив его со списком держателей акций,  при необходимости отредактировать его параметры и авторизовать («забукировать») платеж.
• Переоценка (Revaluation). При использовании многовалютного учета используется специальный бухгалтерский сервис, ежедневно приводящий бухгалтерские книги к базовой валюте.

2.3      Модуль корпоративных действий (Corporate Actions)

 

  Рис. 4. Список корпоративных действий, детали одного КД (сплит), исходное сообщение, полученное из Xcitek, список держателей ценной бумаги.

 

 

 

 

Модуль обеспечивает

• Получение информации о корпоративных действиях из внешних источников в формализованном виде. Например, поддерживается формат Telekurs, предоставляющий информацию, в частности, и о российских ценных бумагах..
• Получение информации о корпоративных действиях в виде SWIFT-сообщений. Поддерживаются сообщения нового формата ISO 15022: MT564 для форматированного сообщения и MT568 – для неформатированного. Для совместимости сохранена поддержка сообщений формата ISO 7775  (MT551, MT599).
• Ввод информации о корпоративных действиях вручную и редактировании автоматически полученной информации
• Рассылку полученной информации держателям бумаги, по которой проводится корпоративное действие
• Расчет списков держателей бумаг,  участвующих в корпоративных действиях 
• Расчет дивидендов, доходов по долговым бумагам, и других выплат в денежной форме и в виде бумаг (сплиты, конверсии и т.п.)
• Обработку входящих платежей от эмитентов / платежных агентов, полученных в виде  SWIFT-сообщений
• Начисление исходящих платежей клиентам на основании списков держателей с передачей данных модулю бухгалтерского учета.

Система снабжена интерфейсами для форматов файлов КД, поставляемых Telekurs (Швейцария) и Xcitek (США).

 

Telekurs поставляет информацию о КД практически всех стран, включая российских эмитентов. Объем ежедневно обрабатываемых оповещений обычно составляет от  3,000 до10,000 штук. 

Система преобразует оповещения в две формы – нарративное описание и атрибутно?ориентированное представление. Каждая из форм доступна для редактирования. При подготовке оповещений держателем бумаг первая форма используется для формировании MT568, а вторая – для форматированного MT564.

Примеры атрибутов – код целевой бумаги, ex-date, дата платежа, процент начисления, налог и т.п. Всего система поддерживает несколько сотен различных атрибутов. 

Сообщения Xcitek подвергаются аналогичной обработке, с той лишь разницей, что нарративная форма здесь явно присутствует и в декодировании нет необходимости.

  

  Рис. 5. Представление корпоративного действия в виде набора атрибутов.

 

 

 

Система автоматически распознает оповещения относящиеся к одному и тому же КД. Для этого используются специальные эвристические процедуры, особенно в том случае, когда оповещения получены из разных источников. Пользователи могут вручную объединить КДЮ в том случае если автоматическое распознавание не сработало.

Для оповещения клиентов используются MT564 (форматированное сообщение) или MT568 (нарративное сообщение). Какой тип сообщения будет сформирован отправлен определяется автоматически. Для того, чтобы можно было сформировать MT564 (что предпочтительно, так как позволяет STP обработку на стороне получателя), необходимо выполнение двух условий. Во-первых,  должна быть предоставлен образец MT564 для определенных типов корпоративных действий. Во-вторых, данное КД должно иметь все обязательные атрибуты, необходимые для MT564. В противном случае система автоматически переключается на MT568. 

При использовании системой необходимо различать термины оповещение о корпоративном действии и корпоративное действие. Одно корпоративное действие имеет, как правило, несколько присоединенных к нему оповещений. При присоединении очередного оповещения система автоматически уточняет значения атрибутов корпоративного действия. 

В процессе своей обработки каждое корпоративное действие проходит ряд статусов. Например:

·        Предварительное оповещение

·        Окончательное оповещение

·        Подготовка платежей

·        Платежи

·        Завершение

Основные функции приложения Корпоративные действия:

·        Просмотр списков оповещений о корпоративных действиях полученных из внешних источников (информационных агентств) или введенных вручную. Списки оповещений формируются по различным категориям – по источнику, по диапазону дат и т.п.

·        Просмотр списков корпоративных действий. Для удобства пользователей списки формируются по различным категориям – по статусам, по категориям КД (две основные категории - Выплаты и Реорганизации), по диапазону дат. Кроме того, пользователь имеет возможность  отобрать интересующие его КД по сложному запросу по серии параметров.

·        Ввод корпоративного действия вручную.

·        Редактирование корпоративного действия.

·        Расчет списка держателей вручную. Обычно система автоматически рассчитывает список держателей ценной бумаги, по которой производится корпоративное действие, один раз в сутки. Однако,  пользователь может выполнить эту операцию вручную,  чтобы учесть изменения позиций в результате только что завершенных сделок. При расчете списков акционеров система может как учитывать только уже утвержденные позиции, так и незавершенные сделки (т.е. ожидаемые к получению / поставке). Метод расчета зависит от предпочтения Заказчика, от того, какие даты известны для каждого корпоративного действия, от типа корпоративного действия.  Правила расчета определяются на этапе настройки системы.

·        «Календарная» функция. Обработка ответов на оповещения о  корпоративных действиях. Автоматически обрабатываются ответы, полученные в форме SWIFT?сообщения или введенные через web-интерфейс. Ответы, присланные в виде писем или по факсу, вводятся в систему пользователем. 

  Рис. 6. Календарная функция.

 

·       

 

Предварительный просмотр SWIFT сообщения. Эта функция позволяет пользователям системы просмотреть сообщения (MT564 / MT568) до того, как они будут отправлены,  а также отправить отдельные сообщения вручную. Массовое отправление сообщения происходит раз в сутки. Причинами отправки сообщения являются

o       Получение нового оповещения (сообщение отправляются всем держателям)

o       Появление нового держателя бумаги (сообщение отправляются только ему)

o       Изменение позиций держателей (сообщение отправляются держателям с изменившейся позицией)

·        Примеры отчетов модуля Корпоративных Действий

o       Извещения  держателей о различных стадиях корпоративного действия

o       Предварительные извещения о собрании акционеров

o       Извещение о предстоящем собрании акционеров

o       Решения общего собрания акционеров

o       Формы для голосования на Общем собрании акционеров

o       Предварительные извещения  о выплате Дивидендов

o       Извещения  о начале выплаты Дивидендов

o       Извещения  о суммах Дивидендов выплаченных владельцу.

  Рис. 7. Предварительный просмотр MT564 перед отправкой.

 

 

 

 

2.4     Модуль SWIFT сообщений (SWIFT Messaging)

Модуль предназначен для

• Хранения  SWIFT-сообщений полученных и отправленных системой
• Ввода новых исходящих сообщений вручную
• Поиска SWIFT-сообщений по различным признакам (отправителю, получателю, содержимому полей и т.п.)

Базовый набор типов сообщений, поддерживаемый модулем включает все мообщения 500-ой серии, а также MT950. Однако,  расширение этого набора достаточно легко осуществляется на этапе настройки системы.

  Рис. 8. Приложение SWIFT. Сообщение типа MT515 отображено в структурном и в текстовом представлениях.

 

 

 

 

 

 

Главным достоинством модуля является наличие автоматических интерфейсов к другим модулям системы, в первую очередь, к модулю Сделок и к модулю Корпоративных действий.

STP-архитектура модуля SWIFT обеспечивается следующими автоматическими процессами (см. схему):

• Разборщик (Parser) отслеживает появления входящего сообщения  и загружает его в модуль (базу данных) SWIFT. Система настроена на обработку всех сообщений 500-й группы. Технология Global ST^eP позволяет легко добавлять сообщения других групп, что достигается путем настройки системы. Настройки Global ST^eP поддерживают как ISO 15022, так и устаревший ISO 7555. 
• Интерфейс для входящих сообщений (GATE-IN) анализирует разобранные сообщения и выполняет действия в соответствии с их содержанием, например, создает сделку, продвигает сделку в другое состояние, загружает данные для сверки позиций, добавляет оповещение в модуль корпоративных действий, и т.п.
•  Интерфейс для исходящих сообщений (GATE-OUT) обрабатывает запросы от других модулей системы на отсылку SWIFT-сообщений и помещает сформированные сообщения в модуль (базу данных) SWIFT.
• Генератор (Generator) выгружает сообщение из базы данных в формате, приемлемом для отправки в сеть SWIFT или для загрузки в другие SWIFT-системы (например, TurboSWIFT).   

В отличие от Разборщика и Генератора, которые строго следуют стандарту SWIFT, интерфейсы к другим модулям системы плохо стандартизуются, поскольку сильно зависят от корпоративных стандартов конкретного Заказчика. Одно и то же по смыслу сообщение может быть представлено в разнообразных видах. Отправитель и получатель обычно имеют определенные частные договоренности об использовании конкретных полей.  Поэтому реализация этих интерфейсов зависит от проекта и более трудоемка.  Для их реализации используется метод шаблонов. Интерфейсы реализуются на основе шаблонов, предоставленных Заказчиком. В качестве решений «по умолчанию» используются рекомендации, доступные на сайте SWIFT.

 

2.5      Модуль бухгалтерии и депозитарного учета (Accounting)

Этот модуль является одним из наиболее важных модулей системы. Доступ к функциям этого модуля осуществляется через приложение Сделки. Функции этого модуля можно разделить на следующие группы:

• Автоматические бухгалтерские сервисы
• Полуавтоматические бухгалтерские функции
• Ручные бухгалтерские сервисы
• Бухгалтерские отчеты
• Экспорт бухгалтерских данных

Автоматические бухгалтерские сервисы являются основой STP-систем. Например, когда один пользователь выполняет шаг сделки, система автоматически вносит изменения в бухгалтерские книги, и другой пользователь может немедленно  увидеть эти изменения в бухгалтерских отчетах.

Полуавтоматические бухгалтерские сервисы используются когда все вычисления и подготовку бухгалтерских операций система производит автоматически, а задачей пользователя является лишь проверка этих данных и авторизация («букирование») проводки. Примеры – кастодиальная комиссия, выплата дивидендов. 

Ручные бухгалтерские сервисы используются в случаях неавтоматизированных бухгалтерских операций. Набор этих случаев определяется бизнес?политикой организации, а не ограничением системы. К этой категории также относятся  исправительные проводки.

Примеры бухгалтерских отчетов приведены в описании приложения Сделки. Некоторые отчеты формируются и отсылаются клиентам автоматически.

Модуль бухгалтерии обладает гибкой системой настроек, он одинаково легко настраивается на GAAP и российскую систему учета. Настройки, соответствующие депозитарной системе учета выполнены в соответствии с Инструкцией ЦБ №44 от 1996 г.  

Все настройки легко видоизменяются в соответствии с особенностями ведения бухгалтерского учета и учета ценных бумаг конкретным Заказчиком.

Основные набор отчетов для российских реализаций подготовлен в соответствии с Инструкцией ЦБ №44 . Прочие отчеты создаются в соответствии с внутренними правилами  Заказчика и его пожеланиями.

Примеры отчетов модуля бухгалтерии приведены выше, в разделе Модуль Сделок. Почти все отчеты системы в той или иной мере используют данные бухгалтерского модуля.

Бухгалтерские данные могут передаваться другим Системам, установленным у Заказчика в виде файлов или через межсерверные запросы. 

3         Вспомогательные модули и функции

3.1      Web-интерфейс

Система имеет web-интерфейс для доступа к ней Клиентов по защищенным  протоколам Интернет.  Для каждого клиента, желающего воспользоваться этой возможностью, заводится отдельные логин и пароль, обеспечивающий получения данных по его счетам. 

В настоящей реализации системы web-интерфейс используются для следующих функций

• Получение разнообразных отчетов по счету клиента – данные по прохождению сделок,  выписки со счета, оценка портфеля и т.п.
• Введение ответов на вопросы о добровольных (voluntary) корпоративных действиях.

3.2      Модуль обмена данными и Межмодульные интерфейсы (“Gates”)

Модуль обмена данными (Messaging) - это внутренний модуль системы, предназначенный для .промежуточного хранения разнообразных данных, полученных от смежных систем, установленных у Заказчика, а также  финансовой информации, полученной из внешних источников. Весь обмен информацией с внешним (по отношению к системе) миром происходит через этот модуль, за исключением SWIFT-сообщений. Для последних разработан отдельный модуль, ввиду их структурной сложности и особой важности в системе.

В частности, модуль  обмена данных имеет средства обработки сообщений в формате FIX.

Модуль обмена данными имеет собственное приложение, позволяющее просматривать внешние данные в «сыром» виде и следить за процессом их загрузки в систему. В стационарном режиме, при отлаженной автоматической обработке внешней информации этим приложением пользуются очень редко. 

Смысл межмодульных интерфейсов (GATES) описан выше в разделе SWIFT. Аналогичные интерфейсы, хотя значительно более простые по реализации существуют и к модулю обмена данных. Например, при получении оповещений о корпоративных действиях из Telekurs, действует такая схема.

 

3.3      Модуль фоновой печати

Модуль предназначен для автоматической распечатки документов в связи с определенными событиями в системе. Как правило модуль распечатывает

• Ежедневные отчеты определенного содержания, предназначенные как для внутреннего употребления, так и для рассылки другим участникам бизнеса, например выписки со счета, направляемые по почте.
•  Подтверждения о прохождении определенного шага сделки, направляемые клиентам.

Для использования модуля в локальной сети должен быть выделен принтер, на который будут выдаваться все документы.

В этом же модуле реализованы механизмы автоматической рассылки сообщений по e-mail и факсу. Таким образом, для каждого из видов  рассылаемых сообщений возможны 4 транспорта:

• SWIFT
• E-mail
• Факс
• Распечатка,

причем для каждого из транспортов можно предусмотреть по несколько адресов. 

Какой из транспортов будет использоваться для отправления сообщения каждого типа определенному участнику сделки, определяется на этапе настройки системы. Пользователи системы имеют возможность менять эти настройки самостоятельно.

 

3.4      Модуль администратора системы

Модуль предназначен для выполнения определенных настроек в системе и контроля состояния внутренних параметров и настроек.

Функции модуля:

• Настройки системы
  • Окно «Что нового?», в которое администратор вносит свежую информацию о последних изменениях в системе. Эту информацию пользователи могут видеть в других приложениях системы. 
  • Просмотр списка сценариев, настроенных в системе, с указанием типов и путей сделок в каждом сценарии.
  • Просмотр путей сделок, настроенных в системе – состояний, возможных переходов, действий, которые система выполняет на каждом переходе, в т.ч. типы посылаемых сообщений и авторизуемые бухгалтерские проводки – по деньгам и бумагам. 
  • Просмотр правил автоматического продвижения транзакций, настроенных в системе.
  • Просмотр системных констант - многочисленных параметров, управляющих работой системы. Например, расположение некоторых директорий (например, для получения внешних файлов), номера некоторых  фиксированных счетов  внутреннего учета, некоторые фиксированные даты и т.п.
• Настройки оповещений о системных сбоях (alerts) -  для каждого типа оповещения указывается список операторов и их e-mail адресов, по которым эти оповещения будут рассылаться.
• Настройки системной безопасности и разграничения прав пользователей. Настройки задаются в виде следующих отношений.  
  • Список групп пользователей системы – наследуется из настроек базы данных. Например: КЛИЕНТЫ, МЕНЕДЖЕРЫ, ИНСПЕКТОРЫ и т.п.
  • Группы бизнес- функций, доступных пользователям – например, «продвигать сделки», «просматривать бухгалтерские отчеты», «авторизовать бухгалтерские проводки» и т.п.
  • Отношение между группами пользователей и группами функций, то есть определение какой группе какие функции разрешены. 

3.5      Планировщик автоматических процессов

Поскольку Global ST^eP ориентирована на возможно более полную автоматизацию бизнес-процессов, наличие гибкого планировщика является ключевой потребностью.

Автоматические процессы в системе можно разделить на

• Фоновые, т.е. запускающиеся раз в 3-5 минут. Сюда, в первую очередь, относятся процессы связанные с обработкой SWIFT-сообщений. 
• Ежедневные, т.е. процессы запускающиеся каждый день или каждый рабочий день. Примеры:
  • Получение котировок из внешних источников,
  • получение данных от других систем, установленных у Заказчика, если предполагается обмен в режиме банковского дня
• Еженедельные,  например, очистка системы от устаревших или невостребованных данных (старые котировки, корпоративные действия по бумагам, у которых не оказалось держателей по истечении срока).
• Планируемые. Например рассылка выписок по счету для разных клиентов может быть ежедневной, еженедельной или ежемесячной в зависимости от предпочтений Клиента.

Ежедневные автоматические процессы могут иметь сложные зависимости.

Каждый процесс должен отработать один раз в течении суток, при этом

• Для него задан диапазон времени, в который это должно произойти
• Процесс не должен работать одновременно с некоторыми другими процессами, так как это может привести к блокировкам в базе данных (например, загрузка новых котировок может конфликтовать с удаление старых)
• Процесс должен запуститься только после того, как отработают некоторые другие процессы. Например, загрузка котировок в модуль Сделок не может начаться до того, как файл с котировками загружен с FTP агентства. 

Планировщик процессов ST^eP -архитектуры позволяет гибко планировать и вносить изменения в планировку процессов. Event-driven (управляемый событиями) подход к реализации планировщика позволяет максимально эффективно использовать время вне рабочего дня при круглосуточной автоматической работы системы.

 

В начало